Which Comes First, Requirements or Use Cases?
Jun/19/2020 Filed in: Software Requirements
That was a question posed on the r/businessanalysis Reddit community recently. Below was my response comment to the post.
"To answer the question, we need to put some basic concepts and terminology in context.
The short answer is that requirements are derived from Use Cases. Within the context of your question, this implies that you first identify, define and document the Use Cases.
While that seems logical on the surface, an important consideration is missing from the question. That is, from where are Use Cases derived? And, how do you know that you’ve identified all the Use Cases pertinent to the functional requirements of the software?
Realistically, software requirements don’t originate from the users of software. More precisely, software requirements originate from the needs of the business processes that software users participate in.
To put things in perspective, a Use Case is a collection of information or details about a set of tasks (an activity) performed to accomplish a specific business goal or outcome. The primary subject of a Use Case is the tool a person uses to perform the activity. In other words, a Use Case describes how someone USES a technology object to perform one or more tasks within a business process.
This falsely implies that a set of Use Cases represents all the sub-processes involved in a business process. It’s false because it’s possible that some activities/sub-processes don’t involve the use of technology objects.
To do a thorough job of identifying business opportunities and problems that can be exploited or resolved with technology you must understand the entire business process first. That means identifying every activity/sub-process and every task/step within every activity.
In other words, first define and document the business process. Then identify and isolate the activities involving the use of technology objects (i.e. Use Cases). Then identify what the technology objects must be capable of doing (i.e. requirements) in order to help someone perform their business process role responsibilities.
To summarize, the most important and valuable skill a business analyst can have is the ability to identify, define, document, analyze, and communicate the details of business processes. And to be able to do that from a wide range of contexts and perspectives.
That’s the foundation of your credibility and integrity as a business analyst. You need that foundation to have any hope of effectively identifying and communicating business opportunities, problems, and resolutions. And to motivate business people to take appropriate action in response to your analysis and suggestions.
Thoroughness, completeness, accuracy, and precision are the primary quality metrics of that skill. All guided by the personal values of structure, focus, discipline, and accountability."
"To answer the question, we need to put some basic concepts and terminology in context.
The short answer is that requirements are derived from Use Cases. Within the context of your question, this implies that you first identify, define and document the Use Cases.
While that seems logical on the surface, an important consideration is missing from the question. That is, from where are Use Cases derived? And, how do you know that you’ve identified all the Use Cases pertinent to the functional requirements of the software?
Realistically, software requirements don’t originate from the users of software. More precisely, software requirements originate from the needs of the business processes that software users participate in.
To put things in perspective, a Use Case is a collection of information or details about a set of tasks (an activity) performed to accomplish a specific business goal or outcome. The primary subject of a Use Case is the tool a person uses to perform the activity. In other words, a Use Case describes how someone USES a technology object to perform one or more tasks within a business process.
This falsely implies that a set of Use Cases represents all the sub-processes involved in a business process. It’s false because it’s possible that some activities/sub-processes don’t involve the use of technology objects.
To do a thorough job of identifying business opportunities and problems that can be exploited or resolved with technology you must understand the entire business process first. That means identifying every activity/sub-process and every task/step within every activity.
In other words, first define and document the business process. Then identify and isolate the activities involving the use of technology objects (i.e. Use Cases). Then identify what the technology objects must be capable of doing (i.e. requirements) in order to help someone perform their business process role responsibilities.
To summarize, the most important and valuable skill a business analyst can have is the ability to identify, define, document, analyze, and communicate the details of business processes. And to be able to do that from a wide range of contexts and perspectives.
That’s the foundation of your credibility and integrity as a business analyst. You need that foundation to have any hope of effectively identifying and communicating business opportunities, problems, and resolutions. And to motivate business people to take appropriate action in response to your analysis and suggestions.
Thoroughness, completeness, accuracy, and precision are the primary quality metrics of that skill. All guided by the personal values of structure, focus, discipline, and accountability."